refactor(openspec): consolidate specs by capability and device class - #260

openspec/changes/consolidate-specs/proposal.md:7

• The proposal references scripts/ci/validate_sbmd_v4_specs.py, but other updated docs in this PR reference scripts/ci/validate_sbmd_specs.py as the validator (e.g., openspec/config.yaml). Please standardize on the correct validator script name/path across all docs to avoid sending readers to a non-existent or outdated tool.

- **Governance rule (the durable fix):** encode in `openspec/config.yaml` that OpenSpec specs are authored per capability or per device class — never per concrete driver. A new supported device is added as a `.sbmd.js` driver file governed by the SBMD schema validator (`scripts/ci/validate_sbmd_v4_specs.py`), not as a new spec. This keeps the spec count bounded (~15–25) as drivers scale to 100+.

openspec/changes/consolidate-specs/tasks.md:10

• The task list claims several spec renames/creations (e.g., sbmd-claiming, sbmd-mappers, sbmd-endpoint-resolution, release-process), but the diffs shown keep the original spec directory IDs (e.g., openspec/specs/vendor-product-claiming/, openspec/specs/sbmd-resource-prerequisites/, openspec/specs/device-type-endpoint-resolution/, openspec/specs/release-workflow/). If the intent is to rename spec IDs, the directories should be renamed to match; otherwise the tasks/proposal should be adjusted to reflect that only the titles changed.

- [x] 2.1 Create `sbmd-runtime` from `sbmd-system` + `sbmd-v4-runtime` + `sbmd-script-execution-limits`
- [x] 2.2 Create `sbmd-mappers` from `sbmd-resource-prerequisites` + `sbmd-seed-from-attribute`
- [x] 2.3 Create `sbmd-endpoint-resolution` from `device-type-endpoint-resolution` + `endpoint-cluster-fallback`
- [x] 2.4 Rename `vendor-product-claiming` to `sbmd-claiming`

openspec/changes/consolidate-specs/tasks.md:21

• The task list claims several spec renames/creations (e.g., sbmd-claiming, sbmd-mappers, sbmd-endpoint-resolution, release-process), but the diffs shown keep the original spec directory IDs (e.g., openspec/specs/vendor-product-claiming/, openspec/specs/sbmd-resource-prerequisites/, openspec/specs/device-type-endpoint-resolution/, openspec/specs/release-workflow/). If the intent is to rename spec IDs, the directories should be renamed to match; otherwise the tasks/proposal should be adjusted to reflect that only the titles changed.

- [x] 4.2 Create `release-process` from `changelog-generation` + `release-workflow`

openspec/changes/consolidate-specs/design.md:12

• The diagram still refers to validate_sbmd_v4_specs.py, which does not exist in this repo (the script is validate_sbmd_specs.py).

   governed by    │ validate_sbmd_v4_specs.py + JSON schema   ← not OpenSpec

openspec/changes/consolidate-specs/proposal.md:7

• The proposal references scripts/ci/validate_sbmd_v4_specs.py, but the repository validator script is scripts/ci/validate_sbmd_specs.py (and no validate_sbmd_v4_specs.py exists). This should be corrected to avoid pointing contributors at a non-existent tool.

- **Governance rule (the durable fix):** encode in `openspec/config.yaml` that OpenSpec specs are authored per capability or per device class — never per concrete driver. A new supported device is added as a `.sbmd.js` driver file governed by the SBMD schema validator (`scripts/ci/validate_sbmd_v4_specs.py`), not as a new spec. This keeps the spec count bounded (~15–25) as drivers scale to 100+.

openspec/changes/consolidate-specs/design.md:7

• This design doc references scripts/ci/validate_sbmd_v4_specs.py, but the validator script in the repo is scripts/ci/validate_sbmd_specs.py. The current filename will misdirect readers.

This issue also appears on line 12 of the same file.

- Concrete drivers are already validated by `scripts/ci/validate_sbmd_v4_specs.py` against a JSON schema at build time — a mechanism independent of OpenSpec.

openspec/specs/matter-testing/spec.md:53

• This requirement states “chip-tool is no longer used in any capacity”, but the repository still ships chip-tool in the Docker image and other docs/skills describe using it. Consider scoping this statement to the integration-test harness (cluster classes + device interactor) to avoid a cross-spec contradiction.

The entire `testing/mocks/devices/matter/clusters/` directory SHALL be removed. This includes `MatterCluster` (base class), `OnOffCluster`, `LevelControlCluster`, and `ColorControlCluster`. The `_register_cluster()` method, `get_cluster()` method, and `_cluster_classes` attribute SHALL be removed from `MatterDevice`. `device_interactor.py` (`ChipToolDeviceInteractor`) SHALL be deleted entirely — chip-tool is no longer used in any capacity. The `_set_interactor()` method, `_interactor` attribute, and `_chip_tool_node_id` attribute SHALL be removed from `MatterDevice`. The `device_interactor` plugin registration SHALL be removed from `conftest.py`. Tests SHALL interact with device state through the side-band interface (`device.sideband`) and commission devices directly through the Barton API.